-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ·« ÕÅ
Sent: Monday, April 28, 2008 6:36 PM
To: [email protected]
Subject: [pygame] The introduction of my Google Summer Code Project
Hello every one:
I have proposed to work in the Pygame project in the google summer of code
2008. Fortunately, my application is accepted. My aim is to develop a 2D
real-time physics engine for Pygame. The module will be integrated with Pygame
seamlessly.
Since PyGame is mainly for developing 2D games, this physics engine will aim
for the simulation of 2D rigid body dynamics. The functions of the physics
engine include:
1. Basic functions to set objects physical properties like mass, shape, speed,
force and torque.
2. Support for basic types of joint constraints.
3. Continuous collision detection and basic event callback handling.
4. Stable real-time physics simulation.
I will implement the core functions in C. If you have any advice or idea about
this application, please give it to me. I'd like to make this one as good as I
can with all you people's help of this community, thank you very much.
Zhang Fan
_____
<http://cn.mail.yahoo.com/> 雅虎邮箱，您的终生邮箱！
Let me second the recommendation to make the first part of the project be
building an easy to use bridge to box2d or chipmunk. If nothing else, the
effort of interfacing with an existing library will illustrate far better than
any other method which parts could be smoothed over in writing your own physics
library. The other benefit here, is that if we’ve got a good API, then it’s
fairly straightforward for other people to come along and build interfaces to
different physics engines, say a 2D constrained ODE. As with all things
software related there’s a set of tradeoffs inherent in physics engines
(notably accuracy <> speed), and no one solution is ideal for every game. I
think that’s one of the reasons the sprite module works well, as it it’s core
it’s a fairly simple set of interfaces that are easy to extend for what you
need.
As a bonus, box2d just released a new version last month, with quite a few new
features. Chipmunk might be easier though, given that it was built with ruby
integration in mind. You might also consider that pyglet would probably like a
2d physics library too, and might be interested in working with whatever you
develop.
I mention this, as it sounds from your tone that you’d be stressing ease of use
and accuracy (i.e. stability) over simulation speed, which is exactly the
opposite set of tradeoffs I’m looking for in my next game project.
When you do go forward with building your physics engine, one thing to keep in
mind would be to pick a feature that’s not present in the exisitng physics
engines, and build a good implementation of that to differentiate yourself from
the other projects that are out there. Easy integration with pygame might be
that feature, though I’m not convinced. J
On a similar note, I’d really like to see the vector library/interface that you
write be separate from the physics library, as that would be useful for many
other things than working with a physics simulation. It seems like a lot of
people end up rolling their own vector libraries, and that’s one of the stupid
easy things to make faster in C. I’d love to see a vector interface as easy to
use and full featured as the rect interface we have now. The tricky
optimization bit here would be a clean way to group a large number of vector
operations for speed, much like the numpy hacks that people use today.
---------
John Krukoff
[EMAIL PROTECTED]
