So, yes, I implemented a replay system for IB3. It’s similar to that of IB1’s (with the 5-second periodical recording and synchronization).

While IB1 recorded and synchronized positions and angles of bodies, IB3 will record not only positions and angles of bodies, but also the linear and angular velocities of each body. This SHOULD eliminate any accumulated jittering (apparent out-of-sync) in the playback across computers with different types of processors (processor architectures, to be exact). This also holds a couple of advantages over IB2’s replay system.

In short, IB3’s replay system will have minimal jittering, which will only be limited to the 5-second sync intervals and will not accumulate, and smaller file sizes and export codes. It will also won’t have some of the odd behaviors in the playback of IB2’s replays.

More detail ahead.

So, there are a couple of things that needs to be understood to fully understand why jittering occurs in IB1 and the reasons for IB2’s replay system (as well as how it works).

The first thing to understand is the differences between computer processor architectures; namely, AMD and Intel processors, the two most commonly used processors in consumer and commercial computers). There are entire textbooks on the topic of processor architectures, but the concept to understand is how processors perform math operations for floating point calculations.

The second thing to know is the differences between floating point and fixed point. These are types of single-value storage in the memory of computers. The differences between these types is that floating point provides a much larger range than fixed points due to the fact that floating point uses a computer version of the scientific notation to store the number, while fixed point stores a very limited number of digits and a number as to where the decimal point is located. So fixed point is very limited in range and are usually not precise enough for a lot of things.

Now, the downside to floating point is that it is calculated differently between processor architectures. The differences only exist with extremely precise numbers (numbers with something like 20 digits past the decimal point). In most cases, this difference is not significant enough for most computer operations and programs, but the difference is enough for something that needs that sort of precision, like a physics simulation.

These differences usually only exist in certain math functions like sine and square root. Being a physics engine, Box2D uses a lot of these math functions for its calculations. These minute differences are enough so that there are some differences in how a simulation will turn out in the long run, especially with Rube Goldberg machines that require exact places, speed, and rotation in order for the machine to finish successfully.

Fixed point arithmetic is deterministic because the math operations are performed exactly the same way between processor architectures. So why don’t we use fixed points rather than floating points? As a Flash game, we can’t. Like Java, Flash applications need a Flash plugin to run, and all Flash plugins use floating points. So we are stuck with replay simulations that may not run the exact same way between computers.

Ryan Clark (the original developer of IncrediBots) had the misfortune of experiencing this lack of determinism first hand with the replay system in IB1.

IB1’s replay system records the positions and angles of all the bodies every 5 seconds in a live simulation, and synchronizes with the recorded positions and angles in a playback of the replay. This is enough for a lot of replays, but it is not enough for complicated Rube Goldberg machines that require precise movements, robots with fast movements, or long replays that depend heavily on physics. In these moments, accumulated jittering occurs, where no matter how many times the playback synchronizes, the replay won’t look the same way it was originally played (i.e. precise Rube Goldberg machines not working all the way).

IB2’s replay system is largely different from IB1’s replays. The second replay system records the positions and angles every three frames, or 1/10th of a second during a live simulation. Before playback of the replay, IB2 uses a couple of algorithms to sort of “fill in” the frames between the recorded frames. This solves the jittering problem, but because of the calculations for the calculated frames, it displayed odd behaviors with sudden moving bodies (which caused a sort of “sway” before going fast) and fast rotations (which caused an odd displacement…notorious in non-perfectly balanced wheels). Also, the very frequent recording for the replay also resulted in some very large files and export codes (long replays sometimes gauged at 15MB in file size).

The new IB3 replay system goes back to the occasional recording and synchronization of IB1’s. The main difference: not only does it record the positions and angles, but it also records the linear velocities (speed and direction) and the angular velocities (rotational speed) of each body. The problem with the first replay system was that when the bodies are synchronized during playback, it moves and rotates the bodies, but the original velocities are still in place.

So, for example, a ball in a Rube Goldberg machine didn’t make an exact-size hole and instead bounces off in another direction. When it’s time to synchronize, the ball is moved to where it was supposed to be, but it’s still moving in the other direction because the original velocities were kept in place. This is an extreme case of jittering, but the accumulation of small differences in direction and speed can throw the whole replay off eventually.

Recording the linear and angular velocities should keep jittering to a minimum and should nicely continue the replay after each synchronization. This won’t prevent a single extreme case of jittering like the example I used above, but after the synchronization, it should continue fine so it won’t throw the rest of the replay off. Returning to the occasional recording and synchronizing also significantly reduces the size of files and export codes.

So, hopefully, the new replay system will work fine once IB3 is released for the public!

(Source: incredibots.com)