- Most importantly, I fixed up a few things thanks to issues pointed out by users. Thanks mikkelin, Fahri, dabski, and anyone else that I might have forgotten!
- Updated to the latest Box2D SVN r141 -- there were some changes upstream, including:
- A new RopeJoint (maximum distance constraint)
- Allocator, joint and some other fixes and improvements
- Working b2LoopShapes -- featuring smooth collision both inside and out (you can see these in the character collision test)
- Added the rope joint test
- PyQt4 framework fixes
- Some properties are changeable now (*)
- Fixed updated circle radii between calls
- Epydoc documentation for the 2.1 branch was generated by using the Doxygen documentation for the C++ side (which, although it is included in the SVN, is usually not at all necessary for pybox2d users).
- An up-to-date version of the compiled library is included on the SVN
- It's here. For those of you who would like to help test, is this convenient enough? Or is it "give me an archive or test the damn thing yourself"? :)
(*) Any idea how to properly size a QListWidget in a QTreeWidget cell? I think sizing widgets appropriately is what most frustrates me about Qt.
Posts
Keep plugging away at it, man. I just downloaded the latest version from google code, and plan on trying it out tomorrow. I've messed with pymunk a bit, and look forward to seeing how pybox2d compares.
ReplyDeleteHave you tried pybox2d with Python 3 at all?
Hi Bob,
ReplyDeleteThanks for the encouragement. Do keep in mind that if you downloaded the alpha version -- it is, well, 'alpha'. The 2.0.2b1 builds (from early 2009) are stable as far as I know, but the API is not nearly as nice to deal with as the new versions.
At one point I did have Python 3 working, but I had forgotten about it until you reminded me. I'll look into compatibility with 3.1 this week if I get a chance.
Ken
Well, I haven't had time to fire it up yet. I am working on a small Breakout / Arkanoid clone, and thought it might be neat to try some more interesting physics with it.
ReplyDeleteSo far, I've been using Pygame and Python 3.1, but 2.6 shouldn't cause me any real problems. When I looked at pymunk, it seemed a bit too buggy for me on either 2.6 or 3.1, so I thought I'd look at something else.
Good luck. I'm glad to see this is an active project as it looks like only one of two 2D physics libraries for python.
Sorry, I almost forgot to ask. Do you have any links to some good tutorials / examples? I'm a lazy learner, and find it easier if I can see something step-by-step or at least see how someone else did things.
ReplyDeleteI think most programmers are that way, Bob. There was a decent manual that described how to get started for 2.0.2, but I'm afraid I still haven't gotten around to porting over the 2.1.0 manual. (for 2.0.2, this can be found here -- mind you, it's essentially unusable for 2.1.0)
ReplyDeleteUnfortunately, your best bet at this point is the testbed (2.1 testbed, old 2.0 testbed). It's overcomplicated for simple examples, but you should be able to see how the bodies/fixtures/shapes match up with the output when experimenting.
Looking over the testbed really makes me want to come up with just very basic pygame examples that people can use to learn (without the testbed). Yet another thing to get around to doing...
So, are there a lot of differences between 2.0.2 and 2.1.0? I'm going to print out the manual for 2.0.2 and give it a look-over.
ReplyDeleteThanks.
2.0.2 and 2.1.0 are very different -- although the underlying functionality is similar, the interface has changed greatly. 2.1.0 utilizes properties and kwargs everywhere possible to make things easier. 2.0.2 is very close to the C++ version, with a few added benefits.
ReplyDeleteI must be missing something because I can't seem to set the AABB for the world. It seems like it's no longer part of the __init__ function. I'm sure it's something simple, but I am having a difficult time following the testbed code with the whole pygame framework thing. When I try looking at it, I just end up more confused than I started. :(
ReplyDeleteBob, my guess is you're trying to follow the 2.0.2 guide using the new 2.1.0 version. It's no longer possible to set the world AABB because -- well, there is no more world AABB.
ReplyDeleteOne benefit of the testbed is that you don't have to worry about creating the b2World and deal with pygame when you want to just test out how shapes and everything work in box2d. It allows you (as in all of the test_*.py examples) to create interactive polygons, circles, and whatnot in the world and have them displayed for you regardless of the backend (pygame, pyglet, pyqt4).
As much as I hate to send off potential users, my recommendation to you would be to wait until I port the 2.1.0 manual. I've finished most of my todo list for the code, so it should be coming up soon. After getting the documentation done, maybe I'll come up with some bare minimum examples for people to get simple non-testbed projects going.
OK, thanks for the time. I'm actually trying to use it with pyglet. Maybe I'll take another look at the testbed again for 2.1.0. I have done some pygame stuff, but the framework code appeared a little daunting to me at first look.
ReplyDeletePerhaps I'll just give it a try with the 2.0.2 version. I just have a small breakout game I'm trying so I can get a feel for the physics stuff.
Thanks again, and good luck with polishing off the rest of the new version. If you want, I can send you what I have for the graphics portion of my project using pyglet for another example.
No problem.
ReplyDeleteIf you ever wade through the testbed and figure out what makes it so daunting, let me know. I'd be keen to simplify it as much as I can.
I'd definitely appreciate any help with pyglet that you could offer. Fixing up that backend is on my todo list. :)
Thanks. I'll definitely take a look at it. I think the scary part to me is just that the framework is quite a bit of code to go through.
ReplyDeleteI'm an electrical controls engineer who does python for some internal company software and a bit of fun on the side so I'm by no means a trained software engineer, but the whole framework thing just seems rather over-engineered for simple examples.
I would rather see smaller, more atomic examples that show one or two principles without bogging the newcomer. The pymunk examples seem to take that approach, and it just seems easier to get up to speed with the basic concepts (I don't have to look at multiple files to figure out how things are initialized, defined, etc.)
I used to play mostly with Pygame for graphics, but decided to give Pyglet a whirl. It might not have some of the features of Pygame, but (so far) Pyglet seems cleaner to use.
Keep up the good work.
Well, I agree up to a point. The framework examples themselves were intended to be simple, which they for the most part are. The back ends admittedly are much more complicated, but they also show how to do just about everything you could want to do (assuming you can pick it apart).
ReplyDeleteBut I always seem to come back to this one point -- when creating these small examples, what do you include? Basic world and shape creation? Of course. An event loop? Absolutely. Converting world->screen coordinates? Yeah, unless using a graphics library that will do it for you. Drawing of circles? Not quite enough. Drawing of all shapes? Yeah. Object picking? Examples aren't terribly interesting without interactivity. Toggling drawing/tuning parameters? Can be vital depending on the specific application.
OK, say there are at minimum 30 individual examples for all of these. Multiply that number by 3 or 4 for each back-end, and all of a sudden you have a maintenance nightmare for just one person.
Ignoring that, just think about the introduction of a debug drawing class in an example -- that adds a couple hundred lines of code (depending on the back-end). Leave that out, and nobody wants to play with your physics library anymore.
I do like pyglet and the direction it's going, but I focus on pygame as it appears to be what most people like to use.