3 ms·

> because floating point math differs slightly between different processors. I don't know why you keep saying this. If I compile a program which uses floating

> because floating point math differs slightly between different processors. I don't know why you keep saying this. If I compile a program which uses floating point for (say) x64, it will produce the same results on every machine. Can you give any example where the same executable will produce different results on different machines? Now, you may get different answers on ARM, or 32-bit, but almost no games (I'm having trouble thinking of any) try to do cross-CPU networking, so the (extremely) minor differences doesn't make any difference. Most games don't sync between users, they trust each user to run the game engine -- you can't afford to send the total state of the world to users, it would take far too much network traffic. Can you point me to a physics engine which gives 100% repeatable results with tickless? I'm genuinely interested, I didn't know of any that claim they achieve that, the common ones (box2d, unity and havok for example) certainly don't.

wareya 10y ago
>I don't know why you keep saying this. Because it's true. The same operation on the same data may give different results on different CPUs, even if you're operating at the machine code level (no implementation-specific optimizations). https://randomascii.wordpress.com/2013/07/16/floating-point-determinism/ https://randomascii.wordpress.com/2013/07/16/floating-point-... https://randomascii.wordpress.com/2014/10/09/intel-underestimates-error-bounds-by-1-3-quintillion/ https://randomascii.wordpress.com/2014/10/09/intel-underesti... >Can you point me to a physics engine which gives 100% repeatable results with tickless? I'm genuinely interested, I didn't know of any that claim they achieve that, the common ones (box2d, unity and havok for example) certainly don't. box2d is sufficiently low level that it gives programmers the tools necessary to do this. Most notably, box2d provides the following: >Continuous physics with time of impact solver This directly allows developers to create a "tickless" physics simulation by breaking up the simulation into the timespans between interactions, as long as pathological situations aren't introduced (like the quake 3 ledge climbing bug). That doesn't mean that the developer will actually do so, and if the gameplay logic interacts with physics in framerate-dependent ways the result will still be wrong. It just means that the possibility is there. Of course, this doesn't solve game logic issues with things happening only at the moment that a frame happens. That's entirely on the developer, even if they use an ideal physics engine. At the end of this, I'll repeat that fixed timestep doesn't actually solve the problem, all it does is allow you to output higher graphical framerates than the physics simulation is running at. If the physics simulation itself can't run at full speed, you still need a way to adapt to longer frametimes, and you have to do so correctly. And if you run the physics simulation so slowly that it won't slow down on any reasonable PC, you either have a very simple game or you just added tons of input latency.
- buzzybee 10y ago
  The reason why you don't see an issue while using Box2D is because its integration methods are low-error. A simple platform game using Euler style integration of the type each step, add forces from input and gravity. add the resulting acceleration multiplied by time to my position. will trivially produce jump heights of 50% variation when subjected to a variable timestep. On a quick search, Box2D uses semi-implicit Euler [0], which much more accurately fits the curve. It does not guarantee zero error: to do that you have to have an analytic method, which isn't applicable to a general-purpose physics simulation. [0] https://en.wikipedia.org/wiki/Semi-implicit_Euler_method https://en.wikipedia.org/wiki/Semi-implicit_Euler_method edit: i did forward euler wrong
  - wareya 10y ago
    I covered integration error in my first post here, point 3. The thing I was calling Box2D out for is the fact that it doesn't use a hacky way of rectifying collisions. It seeks out the point in time that they occur. >It does not guarantee zero error: to do that you have to have an analytic method, which isn't applicable to a general-purpose physics simulation. If you have constant acceleration, the analytic way to get the point you want to be at at the end of the frame is simple: just pretend your current frame is using half the added speed from the acceleration that you're going to undergo this frame. Or you could use a hermite curve or something.
    - buzzybee 10y ago
      Those are the integration methods I was talking about. An analytic method without error is one which can describe the curve at any moment in time, not "constant acceleration per frame".
- ewjordan 10y ago
  Box2d's continuous physics does not allow for a tickless simulation as I understand the term, because continuous interactions (stacking, sliding, rolling, etc.) are not reduced to discrete time-of-impact calculations. Joints are also in that category. If you run the testbed and crank the timestep way up, you'll definitely see problems with things like ragdolls. Continuous collision detection definitely makes it easier to handle high velocities and bigger timesteps, but it's not a panacea.

wareya 10y ago

>I don't know why you keep saying this. Because it's true. The same operation on the same data may give different results on different CPUs, even if you're operating at the machine code level (no implementation-specific optimizations). https://randomascii.wordpress.com/2013/07/16/floating-point-determinism/ https://randomascii.wordpress.com/2013/07/16/floating-point-... https://randomascii.wordpress.com/2014/10/09/intel-underestimates-error-bounds-by-1-3-quintillion/ https://randomascii.wordpress.com/2014/10/09/intel-underesti... >Can you point me to a physics engine which gives 100% repeatable results with tickless? I'm genuinely interested, I didn't know of any that claim they achieve that, the common ones (box2d, unity and havok for example) certainly don't. box2d is sufficiently low level that it gives programmers the tools necessary to do this. Most notably, box2d provides the following: >Continuous physics with time of impact solver This directly allows developers to create a "tickless" physics simulation by breaking up the simulation into the timespans between interactions, as long as pathological situations aren't introduced (like the quake 3 ledge climbing bug). That doesn't mean that the developer will actually do so, and if the gameplay logic interacts with physics in framerate-dependent ways the result will still be wrong. It just means that the possibility is there. Of course, this doesn't solve game logic issues with things happening only at the moment that a frame happens. That's entirely on the developer, even if they use an ideal physics engine. At the end of this, I'll repeat that fixed timestep doesn't actually solve the problem, all it does is allow you to output higher graphical framerates than the physics simulation is running at. If the physics simulation itself can't run at full speed, you still need a way to adapt to longer frametimes, and you have to do so correctly. And if you run the physics simulation so slowly that it won't slow down on any reasonable PC, you either have a very simple game or you just added tons of input latency.

buzzybee 10y ago
The reason why you don't see an issue while using Box2D is because its integration methods are low-error. A simple platform game using Euler style integration of the type each step, add forces from input and gravity. add the resulting acceleration multiplied by time to my position. will trivially produce jump heights of 50% variation when subjected to a variable timestep. On a quick search, Box2D uses semi-implicit Euler [0], which much more accurately fits the curve. It does not guarantee zero error: to do that you have to have an analytic method, which isn't applicable to a general-purpose physics simulation. [0] https://en.wikipedia.org/wiki/Semi-implicit_Euler_method https://en.wikipedia.org/wiki/Semi-implicit_Euler_method edit: i did forward euler wrong
- wareya 10y ago
  I covered integration error in my first post here, point 3. The thing I was calling Box2D out for is the fact that it doesn't use a hacky way of rectifying collisions. It seeks out the point in time that they occur. >It does not guarantee zero error: to do that you have to have an analytic method, which isn't applicable to a general-purpose physics simulation. If you have constant acceleration, the analytic way to get the point you want to be at at the end of the frame is simple: just pretend your current frame is using half the added speed from the acceleration that you're going to undergo this frame. Or you could use a hermite curve or something.
  - buzzybee 10y ago
    Those are the integration methods I was talking about. An analytic method without error is one which can describe the curve at any moment in time, not "constant acceleration per frame".
ewjordan 10y ago
Box2d's continuous physics does not allow for a tickless simulation as I understand the term, because continuous interactions (stacking, sliding, rolling, etc.) are not reduced to discrete time-of-impact calculations. Joints are also in that category. If you run the testbed and crank the timestep way up, you'll definitely see problems with things like ragdolls. Continuous collision detection definitely makes it easier to handle high velocities and bigger timesteps, but it's not a panacea.