I am reading this article on how to control the framerate and physics calculations.

But in the game I am writing, I use a third party physics library and the only thing I do to update my physics is call a single function (runSimulation()).

Since I cannot do things like "interpolation" in the above tutorial, how can I make my game runnable in different hardware/at different framerates?

  • 1
    \$\begingroup\$ Are you currently having any problems so far, and do you think the 3rd party physics simulator you are using isn't using all those techniques? (As far as possible) \$\endgroup\$ – Roy T. May 25 '12 at 9:26
  • \$\begingroup\$ Actually in the physics engine source code ,it doesn't use any time variable for calculations \$\endgroup\$ – Ashika Umanga Umagiliya May 25 '12 at 9:51
  • \$\begingroup\$ In that case it might be better to look for another (better?) physics library. Or maybe ask the developers there what they think. Or maybe they expect you to call the runSimulation step exactly every x-miliseconds. \$\endgroup\$ – Roy T. May 25 '12 at 10:52

Looks like the SteeringBehaviors library is determining the simulation time by calling System.currentTimeMillis(), so (unless you modify the library) your only option is to call runSimulation() at exactly the right time.

Consider spawning 2 threads:

  1. Execute Thread 1 every time the display needs to be updated (e.g., by syncing to the display's refresh interval)
  2. Execute Thread 2 every time you want to update the simulation. Make sure this thread executes at the same rate on different platforms (e.g., by setting it up to fire using a fixed-rate timer).

(And, of course, be sure that any data structures shared between those two threads (the locations of the particles, for example) are protected from thread collisions (e.g., using locks).)

That way, if the rendering thread stalls, or if the rendering speed differs between hardware devices, your simulation thread will continue to update the simulation at a constant rate.

| improve this answer | |
  • \$\begingroup\$ Using a separated thread is a good answer, but may be too overwhelm . \$\endgroup\$ – Gustavo Maciel May 26 '12 at 4:15
  • \$\begingroup\$ Overwhelming in what sense? \$\endgroup\$ – smokris May 26 '12 at 4:20
  • 1
    \$\begingroup\$ Almost all non-trivial physics simulations run in their own, fixed time rate threads just like @smokris describes above. \$\endgroup\$ – Patrick Hughes May 26 '12 at 5:19
  • 1
    \$\begingroup\$ I don't think the OP is treating a non-trivial physics simulation. It's not overwhelming in sense of performance, but implementation. Getting threads very sync, and out of dead locks is not a trivial task. \$\endgroup\$ – Gustavo Maciel May 26 '12 at 15:56
  • 1
    \$\begingroup\$ This is a pretty straightforward use of threads though. OP would just need to share the particle-location data structure between the two threads, which would just require a single lock. No risk of deadlock. \$\endgroup\$ – smokris May 26 '12 at 19:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.