You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: VERSION.txt
+2-2Lines changed: 2 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -210,7 +210,7 @@ Keep in mind that this is a x.0.0 release and that it's likely there are still s
210
210
What's new in 5.3.5
211
211
* FIX: Fixed spelling of cpArbiterGetDepth(). Was cpArbiteGetDepth() before. Apparently nobody ever used this function.
212
212
* FIX: Added defines for M_PI and M_E. Apparently these values were never part of the C standard math library. Who knew!?
213
-
* FIX: Added a guard to cpBodyActivate() so that it's a noop for rouge bodies.
213
+
* FIX: Added a guard to cpBodyActivate() so that it's a noop for rogue bodies.
214
214
* FIX: Shape queries now work with (and against) sensor shapes.
215
215
* FIX: Fixed an issue where removing a collision handler while a separate() callback was waiting to fire the next step would cause crashes.
216
216
* FIX: Fixed an issue where the default callback would not be called for sensor shapes.
@@ -297,4 +297,4 @@ What's new in 5.1.0:
297
297
What's new in 5.0.0:
298
298
* Brand new Joint/Constraint API: New constraints can be added easily and are much more flexible than the old joint system
299
299
* Efficient Segment Queries - Like raycasting, but with line segments.
300
-
* Brand new collision callback API: Collision begin/separate events, API for removal of objects within callbacks, more programable control over collision handling.
300
+
* Brand new collision callback API: Collision begin/separate events, API for removal of objects within callbacks, more programable control over collision handling.
Copy file name to clipboardExpand all lines: doc-src/chipmunk-docs.textile
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -274,7 +274,7 @@ Static bodies are bodies that never (or rarely) move. Using static bodies for th
274
274
A graphics engine only needs to know the position of an object for each frame that its drawn. For a physics engine, this isn't enough information to calculate a collision response. When you set the position of a body, you are effectively asking it to teleport itself. This means that it will instantly move to its new position instead of moving through space and time like a normal object. If you teleport an object so that it overlaps another one, the best the physics engine can do is to attempt to push the objects apart again since there is no information about their movement. This generally results in very mushy looking collisions. So instead of setting the position of an object, it's better to set its velocity and allow the physics engine to update the position. That way it can resolve any resulting colisions natuarally since it knows how the objects were moving. This is why kinematic bodies work the way they do. You set the velocity, and the physics updates their position so the two are never out of sync.
275
275
276
276
277
-
For dynamic bodies, setting the velocity explicitly every frame can cause problems. For example, a problem occurs when a light dynamic body (like a person) is pressed against a heavy dynamic body (like a car), and you set velocity of the small object so that it's pushing it into the big body. To the physics engine, the change in velocity is the same as applying a large impulse (a very short, very large force). Even if the velocity is low, the large force can allow the small body to push the big body, even when it normally wouldn't be able to. For example, a person walking into a car can overpower the car's friction and cause it to creep along the ground slowly. Additionally, when you set the velocity of an object that is already in contact, it can cause the two objects to overlap by a small amount. The easiest way to avoid both of these problems is to make smaller changes to the body's velocity, accelerating it over a fraction of a second instead of a single frame. An even better solution, which is covered more thoroughly later, is to use constraints to move the object.
277
+
For dynamic bodies, setting the velocity explicitly every frame can cause problems. For example, a problem occurs when a light dynamic body (like a person) is pressed against a heavy dynamic body (like a car), and you set velocity of the small object so that it's pushing it into the big body. To the physics engine, the change in velocity is the same as applying a large impulse (a very short, very large force). Even if the velocity is low, the large force can allow the small body to push the big body, even when it normally wouldn't be able to. For example, a person walking into a car can overpower the car's friction and cause it to creep along the ground slowly. Additionally, when you set the velocity of an object that is already in contact, it can cause the two objects to overlap by a small amount. The easiest way to avoid both of these problems is to make smaller changes to the body's velocity, accelerating it over a fraction of a second instead of a single frame. An even better solution is to use constraints to move the object. For an example, look at how the Tank and Crane demos drive their constraints and use the maximum bias and force properties. The mouse control in the demo application works the same way.
278
278
279
279
<%= h 2, "Memory Management Functions:", "Memory" %>
0 commit comments