See Particles.coffee
Some of the code already works (deactivated) but it was ugly.

• Optimize buffer size?
• Create second buffer to only compute the borders of the main buffer?
• Completely remove the buffer since this is a lot faster than before and the copy-paste of pixels of buffer takes too much time ?

See EdgeEffect in https://github.com/MichaelHoste/xmoto.js/blob/master/data/Themes/modern.xml

Maybe it's not soooo useful since the edges have no impact at all on physics and are just cosmetic

best replay will not always be a ghost

Move camera left/right/up/down depending on moto direction and moto speed
(transfer @object_to_follow to camera)

And check that nothing is displayed off the borders of the screen

NOW

Currently the replays are saved with :

1. positions of left_wheel, right_wheel, body, torso, upper_leg, lower_leg, upper_arm, lower_arm. And also an information about moto direction (left or right).
2. Each position is represented by x, y and angle (we only keep 2 decimals precision (1 cm) to create smaller files and smaller network communications. And separators are needed to separate all the numbers.)
3. 10 frames par second for replays are a good compromise (one frame every six). The other frames are interpolated when the replays are run.

Size : So, for every minute of replay, we need about 9 moto parts x 3 values x 6 chars ("00.00" + separator) x 10 frames x 60 seconds = **~ 100ko** of disk space.

We save about half of this size by compressing with lz-string but it's not enough if we want to have millions of saved replays

And while it works fine, we may have a problem when we'll introduce physics elements in the level because each of the "movable" element will need to have all its positions saved as well !

Pros:

• It's already working.
• It's really fast to run a replay (no physics recalculations).

Cons:

• Heavy replay files (100ko/min)
• Cheat-friendly (No really easy way to know if a replay if legit)
• Doesn't work if other physics objects in the level (boxes, elastic bridges, etc.).

Improved solution?

Since the physics of the game is created so that it doesn't depend AT ALL on the framerate and is always fixed as 60 steps/second, we should be able to re-create every replay with only the player's inputs (up, down, left, right, space).

Pros:

• Light replay files.
• More difficult to cheat (replays are legit since the physics are computed again each time).
• Work well with other physics objects in the level (boxes, elastic bridges, etc.).

Cons:

• Slower to run replays (but don't seem critical)

Solution 1

We know that each input is either true or false, at anytime (a key is pressed or it is not). So we could consider storing inputs in binary format with a small library like bitview.js.

We'll need only 6 bits per physics step : up, down, left, right, space and another bit for a potential future input (like a boost). In this situation, we must save each one of the 60 steps per second.

Size : 6 bits x 60 steps x 60 seconds = 21600 bits = 2700 octets = 2.6ko. About 40 times less than the previous format !

And with this solution, we can introduce movable physics elements without even thinking about saving them since the physics engine will reproduce exactly the same behaviour without any additional information.

The only counterpart is that it will need more CPU power to re-generate the new positions of the ghosts. But Box2D is fast and the drawings are much more CPU intensive.

Solution 2

Instead of keeping the "true" or "false" information of every input at each step, we could try keeping only the changes of these inputs.

If the player start pressing "up" at step 100 and stop at step 120, and then press again at 159 and stop at 201, we could only save :

{ 
  up_pressed: [100, 159], 
  up_released: [120, 201]
}

It could be interesting since there will have far less actions than steps. According to my tests, there are about 200 input changes every 60 seconds. A rate of about 3 or 4 by second.

If we store the replays like this 100,159|120,201,... and supposing replays are shorter than 3 minutes (so steps of less than 4 digits) with a separator.

Size: (4 digits + 1 separator) x 200 = 1000 octets = 1ko. Even less than the previous format without even using binary representation!

And we still can compress with lz-string to save about 50% of the final size. We get to a point where we could store the replays in the DOM of the web pages and not getting them by additional HTTP requests.

Solution 3

Same as solution 2 but instead of storing up_pressed: [950, 1010] where the up key is pressed at step 950 and then 1010, we could store as up_pressed: [950, 60] for the same behaviour, where each number represents the delta since the last action.

In this simple example we gain 2 digits/octets on the final representation.

Better for AngularJS (among others) to inject options to XMoto (DOM is refreshed "when it has time so we needed to use setTimeout)

(Use "watch" on AngularJS)