Question

I’m 100% new to threading, as a start I’ve decided I want to muck around with using it to update my physics in a separate thread. I’m using a third party physics engine called Farseer, here’s what I’m doing:

// class level declarations
System.Threading.Thread thread;
Stopwatch threadUpdate = new Stopwatch();

//In the constructor:
PhysicsEngine()
{
(...)

            thread = new System.Threading.Thread(
                        new System.Threading.ThreadStart(PhysicsThread));
            threadUpdate.Start();

            thread.Start();
}


        public void PhysicsThread()
        {
            int milliseconds = TimeSpan.FromTicks(111111).Milliseconds;
            while(true)
            {
                if (threadUpdate.Elapsed.Milliseconds > milliseconds)
                {
                    world.Step(threadUpdate.Elapsed.Milliseconds / 1000.0f);
                    threadUpdate.Stop();
                    threadUpdate.Reset();
                    threadUpdate.Start();
                }
            }
        }

Is this an ok way to update physics or should there be some stuff I should look out for?

Answer 1

In a game you need to synchronise your physics update to the game’s frame rate. This is because your rendering and gameplay will depend on the output of your physics engine each frame. And your physics engine will depend on user input and gameplay events each frame.

This means that the only advantage of calculating your physics on a separate thread is that it can run on a separate CPU core to the rest of your game logic and rendering. (Pretty safe for PC these days, and the mobile space is just starting to get dual-core.)

This allows them to both physics and gameplay/rendering run concurrently – but the drawback is that you need to have some mechanism to prevent one thread from modifying data while the other thread is using that data. This is generally quite difficult to implement.

Of course, if your physics isn’t dependent on user input – like Angry Birds or The Incredible Machine (ie: the user presses “play” and the simulation runs) – in that case it’s possible for you to calculate your physics simulation in advance, recording its output for playback. But instead of blocking the main thread you could move this time-consuming operation to a background thread – which is a well understood problem. You could even go so far as to start playing your recording back in the main thread, even before it is finished recording!