Working with Physics Manual Vintage
I picked up a copy of the Physics Manual Vintage about three years ago after finding it archived on a defunct dev forum. It's not a mainstream reference, so you won't find reviews or tutorials for it anywhere obvious. That said, it covers rigid body dynamics, collision response, and basic joint constraints in a way that's actually usable if you read it carefully. The manual is organized around a coordinate system that assumes the reader already knows linear algebra at an undergraduate level. Chapter 3 jumps straight into quaternion rotation without defining what a quaternion is first. I learned the hard way that skipping ahead here produces wildly incorrect orientation data. I spent two days debugging a simulation where objects were spinning along diagonal axes they shouldn't have touched, only to realize I never normalized my quaternions after each integration step.
Physics Manual Vintage implementation notes
Download the PDF from archive.org or various retro gaming dev repositories. Search for "Physics Manual Vintage filetype:pdf" and you'll find mirrors. The author posted the source code alongside the manual in the original release, which helps because the examples contain minor typos in the equations. The core method the manual teaches is a semi-implicit Euler integrator paired with impulse-based collision resolution. This is standard stuff in modern engines, but the manual frames it differently. It uses an impulse accumulation approach where multiple collisions in a single frame are resolved sequentially rather than simultaneously. This is simpler to implement but introduces energy drift in stacks of objects. If you're building something static, it works fine. If you're stacking more than ten objects, you'll see jitter after about five seconds of simulation time. Here's what the manual doesn't warn you about: the impulse resolution order matters significantly. The manual processes collisions in insertion order, which means the last object added to the scene gets resolved against the rest of the stack every frame. I ran into a case where a simple two-block tower would collapse immediately because the bottom block was always processed last and received accumulated residual velocity from the top block's corrections. The workaround was to sort the collision pairs by contact depth before resolving them. Objects deeper in the hierarchy get corrected first, and the residual errors don't propagate upward.
The damping implementation in this manual is another area that needs attention. It applies a uniform damping factor to all velocities each frame, which looks correct on paper but causes objects to slow down faster in higher gravity settings than intended. The manual defines damping as a percentage of current velocity per second, yet the example code multiplies by dt twice. Once in the velocity update and once in the damping application. This double multiplication means at 60 fps your effective damping coefficient is roughly 60 times larger than what the formula suggests. I caught this by comparing the manual's example output against a brute-force numerical integration in a spreadsheet. The fix is to remove the dt factor from the damping line or adjust the damping constant downward by an order of magnitude depending on your target framerate. The joint system described in chapters 7 and 8 covers hinged joints, sliders, and ball-and-socket constraints. These are implemented using constraint stabilization via positional correction rather than pure impulse methods. The manual uses a Projected Gauss-Seidel solver with a default iteration count of three. Three iterations is enough for simple chains but falls apart quickly with anything more complex. A closed kinematic loop with four joints will not converge at three iterations. You'll need at least eight, preferably twelve, and even then the solver may not fully eliminate drift without adding compliance to the constraints. One thing I wish the manual addressed directly is sleep thresholds. The code provided in the appendix has no built-in sleeping mechanism. Every object simulates every frame regardless of whether it's moving. For a desktop simulation with dozens of bodies, this becomes a noticeable performance problem. I added a simple velocity magnitude check: if an object's speed stays below 0.01 m/s for twenty consecutive frames, flag it as sleeping and skip it in the integrator loop. This cut my frame computation time from about 45 ms down to roughly 8 ms in a scene with thirty active objects, most of which were stationary.
Get the Full Details
The math sections are generally accurate but assume familiarity with matrix inversion. Chapter 4 derives the inertia tensor transformation using a full matrix inversion routine without explaining why the inverse is necessary or what happens when the matrix is singular. I encountered a singular matrix situation when creating a capsule-shaped body with zero radius on one axis. The inertia tensor collapsed and the simulation produced NaN values across the board. The manual never mentions this edge case. My workaround was to add a small epsilon value to any zero or near-zero diagonal element before inversion, which kept the solver stable without materially changing the physics behavior. If you're looking to use this manual for a production project, be aware that it was written before several standard optimizations became common practice. There's no spatial partitioning, no broad phase, and no cache-friendly data layout. The manual's examples use naive O(n squared) collision detection, which is acceptable for five or six objects but completely unusable past about twenty. I ended up pairing the manual's resolution logic with an implicit grid broad phase that I wrote separately. This reduced collision candidate checks from roughly four hundred per frame down to about twenty-five in a typical scene. The manual is available as a standalone PDF with accompanying C source files. It's not maintained anymore, but the core concepts hold up. Just verify every equation against a modern reference like Erin Catto's GDC talks or the Box2D source code if you're unsure about a derivation. The manual gets the fundamentals right but occasionally simplifies or drops terms that matter in edge cases.
