pymunk - Project Hosting on Google Code

Last 7 days Dec 10, 2009 issue 29 (Update to Chipmunk latest) Status changed by v...@viblo.se - Status: Started Status: Started Dec 10, 2009 issue 32 (Vec2d) Status changed by v...@viblo.se - Status: Started Status: Started Dec 10, 2009 issue 32 (Vec2d) commented on by v...@viblo.se - Thanks for the input! As noone has said they like to keep degrees but several indicated they like radians I think Ill go forward with the radians switch. I have done some testing locally and I think Ill rename the current methods (angle_degree and so on) if anyone want to use the old methods. Expect it to be included in the next version, to be released as soon as I've upgraded pymunk to work with the newly released chipmunk 5.0.0 version. Thanks for the input! As noone has said they like to keep degrees but several indicated they like radians I think Ill go forward with the radians switch. I have done some testing locally and I think Ill rename the current methods (angle_degree and so on) if anyone want to use the old methods. Expect it to be included in the next version, to be released as soon as I've upgraded pymunk to work with the newly released chipmunk 5.0.0 version. Last 30 days Dec 09, 2009 issue 32 (Vec2d) commented on by arial.te...@gmx.net - radians, definitely. do it! nao! :) thank you for your efforts radians, definitely. do it! nao! :) thank you for your efforts Dec 04, 2009 issue 32 (Vec2d) commented on by v...@viblo.se - Ive researched this a bit more. I think the only reason for degrees instead of radians was that the vector lib I included in the first release was using degrees, and that I didn't think much about it as the small projects I used it in didn't use the angle functions. And apparently I was wrong in my previous post, pygame does use radians and not degrees.. So, right now Im leaning towards option 2, make the change and break all degree-using code. If the change is to be made, why not do it asap? ;) Ive researched this a bit more. I think the only reason for degrees instead of radians was that the vector lib I included in the first release was using degrees, and that I didn't think much about it as the small projects I used it in didn't use the angle functions. And apparently I was wrong in my previous post, pygame does use radians and not degrees.. So, right now Im leaning towards option 2, make the change and break all degree-using code. If the change is to be made, why not do it asap? ;) Nov 28, 2009 issue 33 (Body.force isn't exposed) changed by v...@viblo.se - Thanks. I have applied your patch. Status: Fixed Owner: v...@viblo.se Thanks. I have applied your patch. Status: Fixed Owner: v...@viblo.se Nov 28, 2009 r216 (Applied patch for Issue 33 (add force propery on Body)) committed by v...@viblo.se - Applied patch for Issue 33 (add force propery on Body) Applied patch for Issue 33 (add force propery on Body) Nov 24, 2009 issue 33 (Body.force isn't exposed) reported by MostAwes...@gmail.com - I need this param for a custom velocity callback, so the attached patch against SVN r215 does the job for me. ~ C. I need this param for a custom velocity callback, so the attached patch against SVN r215 does the job for me. ~ C. Earlier this year Nov 11, 2009 issue 29 (Update to Chipmunk latest) Labels changed by v...@viblo.se - Labels: Priority-High −Priority-Medium Labels: Priority-High −Priority-Medium Nov 10, 2009 issue 32 (Vec2d) Owner changed by v...@viblo.se - Owner: v...@viblo.se Owner: v...@viblo.se Nov 10, 2009 issue 32 (Vec2d) commented on by v...@viblo.se - I remember that we had a reason to use degrees instead of radians, but I don't remember it right now.. I think at least pygame use degrees so that might have been part of the reason. Anyway, do you have what can be done about it now? I guess there are a couple of options: 1. Add corresponding radian-functions to vec2d (something like angle_r?)? This will confuse some as vec2d will contain more functions for no real reason. 2. Change it to use radians. In this case a good time to do it is when pymunk is upgraded to the new chipmunk code. All current code who uses it will have to be rewritten, and anyone who have degrees in their code will have to convert before passing on to pymunk. 3. Do nothing. Meaning everyone who uses radians will have to convert it before chipmunk. Anyway, I don't expect wrapping the cpVect functions to be of any real advantage, a call down into chipmunk is probably about as expensive as doing the calculation directly in python. For these simple calculations its probably the function call overhead thats important and my guess is that its about as expensive (or maybe even cheaper in pure python). Also, my first intuition is that for almost all use cases the conversion is cheap compared to other things pymunk does (but I haven't done any tests :)). Would be really good if you (and anyone else with an opinion on the subject) could comment on what's the best way to handle it? I remember that we had a reason to use degrees instead of radians, but I don't remember it right now.. I think at least pygame use degrees so that might have been part of the reason. Anyway, do you have what can be done about it now? I guess there are a couple of options: 1. Add corresponding radian-functions to vec2d (something like angle_r?)? This will confuse some as vec2d will contain more functions for no real reason. 2. Change it to use radians. In this case a good time to do it is when pymunk is upgraded to the new chipmunk code. All current code who uses it will have to be rewritten, and anyone who have degrees in their code will have to convert before passing on to pymunk. 3. Do nothing. Meaning everyone who uses radians will have to convert it before chipmunk. Anyway, I don't expect wrapping the cpVect functions to be of any real advantage, a call down into chipmunk is probably about as expensive as doing the calculation directly in python. For these simple calculations its probably the function call overhead thats important and my guess is that its about as expensive (or maybe even cheaper in pure python). Also, my first intuition is that for almost all use cases the conversion is cheap compared to other things pymunk does (but I haven't done any tests :)). Would be really good if you (and anyone else with an opinion on the subject) could comment on what's the best way to handle it? Nov 10, 2009 issue 31 (Expose cpBB) changed by v...@viblo.se - Oh. It was included before, but I wasn't sure if it was a "private"/internal structure of chipmunk or not. So, after a couple of version I removed it as no one used it or complained :) But its a simple structure and should be easy to put back now that I know that at least one person wants it. Expect it to be included in the next release. Status: Accepted Owner: v...@viblo.se Oh. It was included before, but I wasn't sure if it was a "private"/internal structure of chipmunk or not. So, after a couple of version I removed it as no one used it or complained :) But its a simple structure and should be easy to put back now that I know that at least one person wants it. Expect it to be included in the next release. Status: Accepted Owner: v...@viblo.se Oct 28, 2009 issue 32 (Vec2d) reported by mason.green - Make the Vec2d class use radians rather than degrees. Chipmunk uses radians by default, and converting back and forth between the two is computationally expensive for Python. Or wrap cpVect? Make the Vec2d class use radians rather than degrees. Chipmunk uses radians by default, and converting back and forth between the two is computationally expensive for Python. Or wrap cpVect? Oct 27, 2009 issue 31 (Expose cpBB) reported by mason.green - This is a very useful bounding box collision detection structure. It would be easy to implement in pure Python, although bindings to C would have a definite performance advantage when querying every body in the game space. This is a very useful bounding box collision detection structure. It would be easy to implement in pure Python, although bindings to C would have a definite performance advantage when querying every body in the game space. Oct 26, 2009 issue 30 (Please remove print statements from Vec2D) changed by v...@viblo.se - Oh. Must have committed by accident. They have been removed in latest trunk. Status: Fixed Owner: v...@viblo.se Oh. Must have committed by accident. They have been removed in latest trunk. Status: Fixed Owner: v...@viblo.se Oct 26, 2009 r215 (removed debug print statements (issue 30)) committed by v...@viblo.se - removed debug print statements ( issue 30 ) removed debug print statements ( issue 30 ) Oct 26, 2009 issue 30 (Please remove print statements from Vec2D) reported by mason.green - In the division section there are multiple print statements. Please remove :) In the division section there are multiple print statements. Please remove :) Oct 25, 2009 issue 28 (Windows 7 x64 build) commented on by v...@viblo.se - mason mailed me that he got it to work by installing 32bit python and using mingw to compile. If anyone else have the same problem, please try with that until the problem is fixed (or compile chipmunk manually to 64 bit, see the README.txt in chipmunk_src folder). And Ill gladly accept a patch for the problem (same with the other issues on the tracker) :) mason mailed me that he got it to work by installing 32bit python and using mingw to compile. If anyone else have the same problem, please try with that until the problem is fixed (or compile chipmunk manually to 64 bit, see the README.txt in chipmunk_src folder). And Ill gladly accept a patch for the problem (same with the other issues on the tracker) :) Oct 25, 2009 issue 28 (Windows 7 x64 build) changed by v...@viblo.se - Ill try to reproduce this on a win2008 machine, but if I cant get any useful info there it will be hard to figure out the problem as I don't have any w7 (or even vista 64bit) to try on. Status: Accepted Owner: v...@viblo.se Ill try to reproduce this on a win2008 machine, but if I cant get any useful info there it will be hard to figure out the problem as I don't have any w7 (or even vista 64bit) to try on. Status: Accepted Owner: v...@viblo.se Oct 25, 2009 issue 29 (Update to Chipmunk latest) changed by v...@viblo.se - My initial thought about chipmunk trunk has been to wait until slembcke release a new version. Part of it has been that the current trunk has some bugs (for example raycasting) and that the api might change/is a bit experimental. Another reason is that I haven't needed the new features myself ;) However, I've gotten a couple requests for the trunk now so maybe its time to make the jump. Judging from the chipmunk forums at least some people do use trunk for their stuff and whyy cant we python programmers be as cool as the c-crowd! Unstable api and bugs can always be worked around or fixed :) Status: Accepted Owner: v...@viblo.se Labels: Type-Enhancement −Type-Defect My initial thought about chipmunk trunk has been to wait until slembcke release a new version. Part of it has been that the current trunk has some bugs (for example raycasting) and that the api might change/is a bit experimental. Another reason is that I haven't needed the new features myself ;) However, I've gotten a couple requests for the trunk now so maybe its time to make the jump. Judging from the chipmunk forums at least some people do use trunk for their stuff and whyy cant we python programmers be as cool as the c-crowd! Unstable api and bugs can always be worked around or fixed :) Status: Accepted Owner: v...@viblo.se Labels: Type-Enhancement −Type-Defect Oct 25, 2009 issue 27 (Missing a way to store userdata in structures) changed by v...@viblo.se - As I haven't got any reply on this Ill assume my example solved your problem, and therefore Ill close this issue. Status: WontFix Owner: v...@viblo.se As I haven't got any reply on this Ill assume my example solved your problem, and therefore Ill close this issue. Status: WontFix Owner: v...@viblo.se Oct 23, 2009 issue 29 (Update to Chipmunk latest) reported by mason.green - Please update Pymunk to the Chipmunk trunk :) Please update Pymunk to the Chipmunk trunk :) Oct 23, 2009 issue 28 (Windows 7 x64 build) reported by mason.green - The Chipmunk build script on Windows 7 x64 fails. The Chipmunk build script on Windows 7 x64 fails. Sep 26, 2009 FAQ (Common questions/problems and how to solve them.) Wiki page edited by v...@viblo.se - Revision r214 Edited wiki page through web user interface. Revision r214 Edited wiki page through web user interface. Sep 26, 2009 FAQ (Common questions/problems and how to solve them.) Wiki page edited by v...@viblo.se - Revision r213 Edited wiki page through web user interface. Revision r213 Edited wiki page through web user interface. Sep 26, 2009 r212 (fixed some python3 incompabilities (might have caused bugs o...) committed by v...@viblo.se - fixed some python3 incompabilities (might have caused bugs on python 2.6 also).. fixed some python3 incompabilities (might have caused bugs on python 2.6 also).. Sep 26, 2009 r211 (changed print statement to work with python 3 as well.) committed by v...@viblo.se - changed print statement to work with python 3 as well. changed print statement to work with python 3 as well. Sep 15, 2009 issue 22 (chipmunk compile is required on x64(linux)) commented on by thehans - This worked perfect, thank you. This worked perfect, thank you. Sep 14, 2009 issue 22 (chipmunk compile is required on x64(linux)) commented on by v...@viblo.se - 1. download the source release of pymunk :) 2. unpack and go do its directory. 2.5 You might need to manually remove libchipmunk.so before the next step. (as it needs to be replaced by the 64 bit version) However, I don't know for sure as I havent tried myself. The file is located in the pymunk subdirectory. 3. run > python setup.py build_chipmunk this command will compile chipmunk for you. 4. run > python setup.py install to install pymunk. (If you don't want to install it you can just as easily place the pymunk directory where your other code is) 5. done! Please let me know if this helped you and I'll add this answer to the FAQ/readme. 1. download the source release of pymunk :) 2. unpack and go do its directory. 2.5 You might need to manually remove libchipmunk.so before the next step. (as it needs to be replaced by the 64 bit version) However, I don't know for sure as I havent tried myself. The file is located in the pymunk subdirectory. 3. run > python setup.py build_chipmunk this command will compile chipmunk for you. 4. run > python setup.py install to install pymunk. (If you don't want to install it you can just as easily place the pymunk directory where your other code is) 5. done! Please let me know if this helped you and I'll add this answer to the FAQ/readme. Sep 13, 2009 issue 22 (chipmunk compile is required on x64(linux)) commented on by thehans - Can someone please explain in detail the procedure to manually compile this? I am on 64bit linux and I can't get this working. I'm very new to this so I'm having a lot of trouble figuring it out. Can someone please explain in detail the procedure to manually compile this? I am on 64bit linux and I can't get this working. I'm very new to this so I'm having a lot of trouble figuring it out. Sep 13, 2009 r210 (added a helpfull error msg if pymunk fails to load the chipm...) committed by v...@viblo.se - added a helpfull error msg if pymunk fails to load the chipmunk lib/dll/dylib file. added a helpfull error msg if pymunk fails to load the chipmunk lib/dll/dylib file. Sep 13, 2009 issue 26 (Failed to load library on FreeBSD system) Status changed by v...@viblo.se - Applied. Also added some code to use the linux/freebsd naming as default if it doesnt find any match. btw, it would be interesting to hear if you have any other problems on FreeBSD or if it works just as good as on Linux? Status: Fixed Applied. Also added some code to use the linux/freebsd naming as default if it doesnt find any match. btw, it would be interesting to hear if you have any other problems on FreeBSD or if it works just as good as on Linux? Status: Fixed Sep 13, 2009 r209 (added changes from txprog to fix issue 26: Failed to load li...) committed by v...@viblo.se - added changes from txprog to fix issue 26 : Failed to load library on FreeBSD system. added changes from txprog to fix issue 26 : Failed to load library on FreeBSD system. Sep 13, 2009 issue 22 (chipmunk compile is required on x64(linux)) commented on by v...@viblo.se - Good to hear that it works good for you! Ive been abroad for a couple of months and therefor haven't been able to set up my own env yet, but will do so soon. If I don't get it to work, Ill ask you for a 64bit package in time for the next relase if I need one. However, its still the question about how to easiest handle it. Bundle both 32 and 64bit files with pymunk and let it decide on startup which one to load? Or maybe just add a check that if the user is on 64 bit, tell him/her to recompile chipmunk... Good to hear that it works good for you! Ive been abroad for a couple of months and therefor haven't been able to set up my own env yet, but will do so soon. If I don't get it to work, Ill ask you for a 64bit package in time for the next relase if I need one. However, its still the question about how to easiest handle it. Bundle both 32 and 64bit files with pymunk and let it decide on startup which one to load? Or maybe just add a check that if the user is on 64 bit, tell him/her to recompile chipmunk... Sep 13, 2009 issue 27 (Missing a way to store userdata in structures) commented on by v...@viblo.se - You can already do this, just add whatever property/data to the shape and you can access it directly in the callback function? I attached the callback demo from the examples dir with a small modification to display how you can do it. (Or maybe I misunderstand what you want?) (Sorry for the late reply, but Ive been away and haven't been able to test myself before now.) You can already do this, just add whatever property/data to the shape and you can access it directly in the callback function? I attached the callback demo from the examples dir with a small modification to display how you can do it. (Or maybe I misunderstand what you want?) (Sorry for the late reply, but Ive been away and haven't been able to test myself before now.) Sep 09, 2009 issue 26 (Failed to load library on FreeBSD system) changed by v...@viblo.se - Thank you for this report and fix! Ill apply it as soon as I have a little time over (Im not on my normal computer right now) Status: Started Owner: v...@viblo.se Thank you for this report and fix! Ill apply it as soon as I have a little time over (Im not on my normal computer right now) Status: Started Owner: v...@viblo.se Sep 08, 2009 issue 27 (Missing a way to store userdata in structures) reported by txprog - If we made a class who manipulate some Segment or Circle as example (like having the same class for physics and drawing), if we want to use the collide callback, you must maintain a ourself the link between the physics and the real class. A userdata property (like a dict) to store any information can be good ! eg: def collide_found(shapeA, shapeB, largs): my_original_class_A = shapeA.userdata['class'] my_original_class_B = shapeB.userdata['class'] class TestClass: def __init__(self): self.seg = pymunk.Segment(body, (0, 0), (10, 0)) self.seg.userdata['class'] = self etc... :) If we made a class who manipulate some Segment or Circle as example (like having the same class for physics and drawing), if we want to use the collide callback, you must maintain a ourself the link between the physics and the real class. A userdata property (like a dict) to store any information can be good ! eg: def collide_found(shapeA, shapeB, largs): my_original_class_A = shapeA.userdata['class'] my_original_class_B = shapeB.userdata['class'] class TestClass: def __init__(self): self.seg = pymunk.Segment(body, (0, 0), (10, 0)) self.seg.userdata['class'] = self etc... :) Sep 07, 2009 issue 26 (Failed to load library on FreeBSD system) reported by txprog - The loadlib.py don't handle FreeBSD case :) An attached patch is provided to fix this OS. The loadlib.py don't handle FreeBSD case :) An attached patch is provided to fix this OS. Sep 07, 2009 issue 22 (chipmunk compile is required on x64(linux)) commented on by txprog - I can provide a 64bits package for linux. It work very well here :) I can provide a 64bits package for linux. It work very well here :) Sep 02, 2009 FAQ (Common questions/problems and how to solve them.) Wiki page commented on by v...@viblo.se - Thats a question that is not specific to pymunk, the same answer should work for pure Chipmunk as well. Meaning you can ask directly on the chipmunk forum to get better help. I did a quick search for top down on it and found: http://www.slembcke.net/forums/viewtopic.php?f=1&t=454&start=0&st=0&sk=t&sd=a&hilit=top+down and also these two that deals specifically with top down cars: http://www.slembcke.net/forums/viewtopic.php?f=1&t=462&start=0&st=0&sk=t&sd=a&hilit=top+down http://www.slembcke.net/forums/viewtopic.php?f=1&t=463&start=0&st=0&sk=t&sd=a&hilit=top+down Thats a question that is not specific to pymunk, the same answer should work for pure Chipmunk as well. Meaning you can ask directly on the chipmunk forum to get better help. I did a quick search for top down on it and found: http://www.slembcke.net/forums/viewtopic.php?f=1&t=454&start=0&st=0&sk=t&sd=a&hilit=top+down and also these two that deals specifically with top down cars: http://www.slembcke.net/forums/viewtopic.php?f=1&t=462&start=0&st=0&sk=t&sd=a&hilit=top+down http://www.slembcke.net/forums/viewtopic.php?f=1&t=463&start=0&st=0&sk=t&sd=a&hilit=top+down Sep 02, 2009 FAQ (Common questions/problems and how to solve them.) Wiki page commented on by paniq303 - What if my physical 2D environment is not seen from the side (with a vertical gravity vector), but from the top? If I don't set any gravity, objects would behave as if in space. Can I simulate z-gravity with friction? What if my physical 2D environment is not seen from the side (with a vertical gravity vector), but from the top? If I don't set any gravity, objects would behave as if in space. Can I simulate z-gravity with friction? Jul 29, 2009 issue 25 (Windows installer application configuration is incorrect) commented on by v...@viblo.se - Ok, I found another issue with pymunk 0.8.3 which made it not work on python 2.5, and therefor created a quickfix release. In the process I also created two msi installers that you can try instead if you still have problems with the .exe windows installer. Ok, I found another issue with pymunk 0.8.3 which made it not work on python 2.5, and therefor created a quickfix release. In the process I also created two msi installers that you can try instead if you still have problems with the .exe windows installer. Jul 29, 2009 pymunk-0.8.4.win32-py2.6.msi (pymunk 0.8.4 windows runtime installer (msi for python 2.6)) file uploaded by v...@viblo.se - Labels: Type-Installer OpSys-Windows Labels: Type-Installer OpSys-Windows Jul 29, 2009 pymunk-0.8.4.win32-py2.5.msi (pymunk 0.8.4 windows runtime installer (msi for python 2.5)) file uploaded by v...@viblo.se Jul 29, 2009 pymunk-0.8.4.zip (pymunk 0.8.4 source release) file uploaded by v...@viblo.se Jul 29, 2009 pymunk-0.8.4.win32.exe (pymunk 0.8.4 windows runtime installer) file uploaded by v...@viblo.se Jul 29, 2009 pymunk-0.8.4.zip (pymunk 0.8.4 source release) file uploaded by v...@viblo.se Jul 29, 2009 pymunk-0.8.4.win32.exe (pymunk 0.8.4 windows runtime installer) file uploaded by v...@viblo.se Jul 29, 2009 r208 (bugfix release 0.8.4 (with correct setup.py)) committed by v...@viblo.se - bugfix release 0.8.4 (with correct setup.py) bugfix release 0.8.4 (with correct setup.py) Jul 29, 2009 r207 (fixed version number in setup.py and added comment in releas...) committed by v...@viblo.se - fixed version number in setup.py and added comment in release creation script to remind me in the future! fixed version number in setup.py and added comment in release creation script to remind me in the future!

issue 32 (Vec2d) commented on by v...@viblo.se - I remember that we had a reason to use degrees instead of radians, but I don't remember it right now.. I think at least pygame use degrees so that might have been part of the reason. Anyway, do you have what can be done about it now? I guess there are a couple of options: 1. Add corresponding radian-functions to vec2d (something like angle_r?)? This will confuse some as vec2d will contain more functions for no real reason. 2. Change it to use radians. In this case a good time to do it is when pymunk is upgraded to the new chipmunk code. All current code who uses it will have to be rewritten, and anyone who have degrees in their code will have to convert before passing on to pymunk. 3. Do nothing. Meaning everyone who uses radians will have to convert it before chipmunk. Anyway, I don't expect wrapping the cpVect functions to be of any real advantage, a call down into chipmunk is probably about as expensive as doing the calculation directly in python. For these simple calculations its probably the function call overhead thats important and my guess is that its about as expensive (or maybe even cheaper in pure python). Also, my first intuition is that for almost all use cases the conversion is cheap compared to other things pymunk does (but I haven't done any tests :)). Would be really good if you (and anyone else with an opinion on the subject) could comment on what's the best way to handle it?

I remember that we had a reason to use degrees instead of radians, but I don't remember it right now.. I think at least pygame use degrees so that might have been part of the reason. Anyway, do you have what can be done about it now? I guess there are a couple of options: 1. Add corresponding radian-functions to vec2d (something like angle_r?)? This will confuse some as vec2d will contain more functions for no real reason. 2. Change it to use radians. In this case a good time to do it is when pymunk is upgraded to the new chipmunk code. All current code who uses it will have to be rewritten, and anyone who have degrees in their code will have to convert before passing on to pymunk. 3. Do nothing. Meaning everyone who uses radians will have to convert it before chipmunk. Anyway, I don't expect wrapping the cpVect functions to be of any real advantage, a call down into chipmunk is probably about as expensive as doing the calculation directly in python. For these simple calculations its probably the function call overhead thats important and my guess is that its about as expensive (or maybe even cheaper in pure python). Also, my first intuition is that for almost all use cases the conversion is cheap compared to other things pymunk does (but I haven't done any tests :)). Would be really good if you (and anyone else with an opinion on the subject) could comment on what's the best way to handle it?

Last 7 days

Last 30 days

Earlier this year