Chipmunk Physics

Anyone have any experience using ChipmunkJS on Android and iOS platforms? I'm doing a networked multiplayer game, and getting different calculation results on the different platforms.

I haven't fully investigated, but at a minimum, the order in which collisions happen (detected in the preSolve callback) does not match. At first, it generates the same collisions but in a slightly different order. But then variables that I introduce in preSolve make the simulation diverge from there.

I'd really appreciate any insights into why this might happen, and how I might be able to address the problems.

- differences in floating point calculations between V8 and JavaScriptCore?
- differences in processing the order of object properties in for(...in) loops? (Since the order is not defined behavior).
- ???

Floating point numbers are not an exact science unfortunately. You will get different results with different compilers, different compiler settings, different CPUs, different ABIs, different JS interpreters, etc. With C compilers there are usually settings to get slow, but exact results. They aren't often used though because it can be a *huge* overhead.

In Javascript, you simply aren't going to be able to fix it. You have to embrace it and work around it. Make one of the devices the server and make sure that you regularly re-synchronize the other devices to it. Latency is going to have even worse effects anyway. If you are doing turn based multi-player, you will have to do the same thing. Run the simulation on one of the devices and send back a keyframed animation or something to the others.

Thank you for the response. This is a Pool (Billiards) game, so there's no substitute for a high-fidelity and matching simulation. It will mean using a something like a fixed-point library for calculations if it comes down to that.

However, I've continued to investigate the problem, and it seems like some FP calculations are consistent between the devices. According to the IEEE spec, it provides algorithms for (and requires exact results for) + - * / and sqrt. Testing showed correlation between those calculations, and it wasn't until expanding into higher-level functions like pow(), sin() or atan2() where differences showed up.

Looks like pow() is only used for damping, and since I'm using a constant step size, that shouldn't be an issue.

Chipmunk doesn't seem to need the trig functions, although I'm using them for things like ball spin and table friction. It might be feasible to use custom approximation functions for those, calculated with consistent operators.

I also sync all values in between shots, so it might be acceptable if the simulation doesn't get too far out of sync on any one shot. Errors can't propagate any further than that. Currently, almost all shots look perfect already, unless there are numerous collisions involved, like in the opening break.

The break discrepancies appear to be caused by Chipmunk processing collision arbiters in an inconsistent order, and I believe I have identified why that happens. The ChipmunkJS port uses "for(key in object)" loops in BBTree.reindexQuery(), and the order of object keys in such a case is not defined behavior. I'm thinking that perhaps changing that operation so that it iterates collisions in consistent order might then result in matching simulations.

The for(..in) loops turned out not to be the culprit.

The problem was Math.pow(), used in damping and collisionBias. It calculates different values on different platforms.

Since I'm running a constant dt, I was able to replace those instances with numeric constants, and that seems to have fixed the inconsistencies. I'm now getting the same simulation on Android and iOS.

Huh. Well that's interesting and surprising.