# How should I invoke a physics engine?

I'm new to writing games. I'm planning to write a 2D battle game which may require an physics engine. Suppose I've written one, but how can I combine it with the main routine of my game? Should I attach it directly to the graphics render routine or put it in an individual thread? I've spent much time looking for some common approach, but found nothing. So can you reveal some basics idea for me, a newbie? Thanks!

P.S. There're many other problems I have to deal with if I choose to start a separate thread for the physics engine, for example, the lock problem, while from my intuition, I guess I'd better separate the render and the physics engine.

• 1. Pick a physics engine. 2. Read the tutorials and getting started guides of the chosen engine. You should separate physics update from other parts of your engine, but don't do it in a separate thread unless you need to. – msell Jul 2 '13 at 5:28
• @msell Umm...I mean how should I couple the update call with the render update. – ymfoi Jul 2 '13 at 6:04

Physics has nothing to do with graphics, so certainly don't put it there. Really, physics is its own subsystem. It takes inputs from game logic (forces to insert into the system) and generates an updated game state (and generates messages for collision updates).

For integration, it's common to have something like:

game loop:
pump events
update input
update AI
update physics
render


The physics update can generate events during collisions so that AI and other game logic can respond to them if appropriate (either by dispatching them immediately or putting them in a buffer for next frame) like triggers or falling damage or whatnot.

It's a huge fallacy to think that each component of the game should get its own thread. A game engine is inherently a serialized beast. If you have 3 systems and put each on their own thread you'll still be massively under-utilizing a 6- or 8-core system, and not even making benefit of the more common 4-core systems. Use a job system instead. Run the system in serial but have each system spawn multiple jobs (handled by a thread pool) to complete its work. Done right, each system scales up to the number of cores in the computer. Some systems demand their own threads for latency reasons (audio processing, networking) but the meat of the simulation benefits more from having many-thread-scalable individual systems rather than a parallel engine design.

• The answer is exactly what I need. Thank you! BTW, can you explain the context near "scales up to the number of cores in the computer" in detail? – ymfoi Jul 2 '13 at 10:30
• Why there won't be performance promotion if I put the engine in a different thread which could be processed by other cores simutaneously? – ymfoi Jul 2 '13 at 13:26
• Many systems are made up of many similar tasks that can run simultaneously. For example, pathfinding for each AI agent does not depend on any other agents. A job system automatically takes parallel tasks like these and spreads them out over all the computer's cores. Therefore, a job system is scalable because it takes advantage of all the available hardware. You do not want to split up each system into its own thread because the systems are very interdependent in a serial manner. The rendering depends on the physics depends on the AI/input, etc. – jmegaffin Jul 2 '13 at 16:08
• you can put each system in its own thread and get some performance improvements, but as I explained that's just not going to gain as much performance as using a job system. paralellizing the whole engine is also much harder. – Sean Middleditch Jul 2 '13 at 16:22
• stackoverflow.com/questions/565137/… – Sean Middleditch Jul 3 '13 at 6:21