# Get different result on different devices (same resolution) after setVelocity

I'm dying with physics , i've tried to use setVelocity however i got slightly different value from different devices.

I've tested on iPhone 5 (on simulator) and iPhone 6 (real device) The Director::getInstance()->getOpenGLView()->getFrameSize() returns both devices is 640x1136 pixels

But i see they have different result after the animation , its about 2-5 pixels. I really don't know why.

I'm making a multiple player game so i need exactly same coordinates of objects on every devices. Does cocos physics return randomly result?

After deep digging, i realize that even i set specific velocity for one object in same device will return different result.

So i don't think this is about the devices, Chipmunk returns different result with the same input parameter!

• My guess would be that it's related to floating point differences. – Richard Marskell - Drackir Oct 3 '16 at 0:15
• @RichardMarskell-Drackir How do i fix it? – TomSawyer Oct 3 '16 at 4:49
• In my experience it's very difficult to align the physics simulations exactly over a network. I think your best bet is to determine which one will be the authoritative host and then simulate it on the other one, but interpolate it so that it aligns to the host's coordinates – Richard Marskell - Drackir Oct 3 '16 at 14:53
• I've read many questions like mine today, and it seems the only solution is simulating physics on the server and emit the result to all clients. Btw i really appreciate your help – TomSawyer Oct 3 '16 at 17:02
• @RichardMarskell-Drackir i've read about simulation physics on the server and predict the movement on the client, but how can i do it if physics engine returns inconsistent results? – TomSawyer Oct 5 '16 at 8:54

You are talking about obtaining a deterministic physics simulation. Are you running a fixed timestep?

https://chipmunk-physics.net/tutorials/ChipmunkColorMatch/Tutorials/ColorMatch-ChipmunkPro-Cocos2D.html

Now let's skip ahead to the update: method. This is the method that Cocos2D calls each time before it draws a frame. The dt variable that it passes is usually going to be about 1/60th of a second, but it's never quite consistent. This is somewhat undesirable for the physics. It's not a good practice to update the physics with these variable sized timesteps because sometimes the CPU might be busy for a few frames. Then the next time you update the physics enough time may have passed so that objects can pass through each other. It also makes the gameplay very non-deterministic and it will act a little differently depending on the framerate.

Instead, you'll want to implement a fixed timestep with Chipmunk. This is really easy to do. I usually do this in all of my games, not just physics ones for the same reasons. Keep the code that updates graphics in update: and create a separate tick: method that handles all the game logic and runs with a fixed timestep. If you want to know more about fixed timesteps, the article in the comment below is a good resource.

• I don't think this is because of timestep. 1 set the initiated velocity, same device, it returns different feedback. sometimes it bounce to the wall,sometimes it stick to the wall. chipmunk doesn't work constantly. I switched to using Box2D and it's pretty good now. – TomSawyer Oct 12 '16 at 3:26

So your physics simulation relies on the visualization of your games' objects on screen? Or is that just the symptom you were able to identify that point to your problem: getting different results for the same algorithms on different machines.

Is it just the positioning on screen that is different, or did you look under the hood as well: Are the calculated results REALLY different?

• I have different results on the same device, same force, same velocity ... I gave up with chipmunk, using box2d and i don't get this stupid error. – TomSawyer Dec 14 '16 at 14:06