3
\$\begingroup\$

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?

\$\endgroup\$
3
  • 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.
    Commented May 25, 2012 at 9:26
  • \$\begingroup\$ Actually in the physics engine source code ,it doesn't use any time variable for calculations \$\endgroup\$
    – Ashika Umanga Umagiliya
    Commented May 25, 2012 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.
    Commented May 25, 2012 at 10:52

1 Answer 1

Reset to default
2
\$\begingroup\$

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.

\$\endgroup\$
5
  • \$\begingroup\$ Using a separated thread is a good answer, but may be too overwhelm . \$\endgroup\$
    – Gustavo Maciel
    Commented May 26, 2012 at 4:15
  • \$\begingroup\$ Overwhelming in what sense? \$\endgroup\$
    – smokris
    Commented May 26, 2012 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
    Commented May 26, 2012 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
    Commented May 26, 2012 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
    Commented May 26, 2012 at 19:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .