Updating docs and typos

Author: slembcke

VERSION.txt

@@ -210,7 +210,7 @@ Keep in mind that this is a x.0.0 release and that it's likely there are still s
 What's new in 5.3.5
 * FIX: Fixed spelling of cpArbiterGetDepth(). Was cpArbiteGetDepth() before. Apparently nobody ever used this function.
 * FIX: Added defines for M_PI and M_E. Apparently these values were never part of the C standard math library. Who knew!?
-* FIX: Added a guard to cpBodyActivate() so that it's a noop for rouge bodies.
+* FIX: Added a guard to cpBodyActivate() so that it's a noop for rogue bodies.
 * FIX: Shape queries now work with (and against) sensor shapes.
 * FIX: Fixed an issue where removing a collision handler while a separate() callback was waiting to fire the next step would cause crashes.
 * 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:
 What's new in 5.0.0:
  * Brand new Joint/Constraint API: New constraints can be added easily and are much more flexible than the old joint system
  * Efficient Segment Queries - Like raycasting, but with line segments.
- * Brand new collision callback API: Collision begin/separate events, API for removal of objects within callbacks, more programable control over collision handling.
+ * Brand new collision callback API: Collision begin/separate events, API for removal of objects within callbacks, more programable control over collision handling.

demo/Planet.c

@@ -95,10 +95,10 @@ add_box(cpSpace *space)
 static cpSpace *
 init(void)
 {
-	// Create a rouge body to control the planet manually.
 	cpSpace *space = cpSpaceNew();
 	cpSpaceSetIterations(space, 20);
 
+	// Create a kinematic body to control the planet manually.
 	planetBody = cpSpaceAddBody(space, cpBodyNewKinematic());
 	cpBodySetAngularVelocity(planetBody, 0.2f);
 

doc-src/chipmunk-docs.textile

@@ -274,7 +274,7 @@ Static bodies are bodies that never (or rarely) move. Using static bodies for th
 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.
 
 
-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.
+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.
 
 <%= h 2, "Memory Management Functions:", "Memory" %>