Quote:Does each graphical entity have its own thread?

No, you really don't want each object to have a thread. Personally, that would drive me insane.

When multithreading, I just look for situations where it doesn't matter if things are done at the same time or not. It doesn't matter if you render an object where it is or where is was 0.016 seconds ago does it? So you should have 1 thread that updates game state and scene graph, and another that renders it. Sure, sometimes you'll render while it's halfway through updating, but it'll look fine. An added bonus is that if the game is minimized or the window is being moved the game still updates, just the rendering thread is stopped. And pausing the game is simple too. The gameplay thread just waits for another pause click and doesn't update till it gets one.

You can do similar (but more difficult) things for physics, animation (if you're not doing it on the gpu anyway) probably other things...

EDIT: Another benifit of multiple threads is you can claim insanely high framerates on machines with fast gpus by limiting the rate the game state thread updates at. No need to tell anyone most of those frames are identical...

Okay. Stumped.

The A.I. and Graphics are going to share a critical section (the entities themselves). Correct? 'Cuz I think I misread your post as the two threads being completely separate from each other.

The downside to that, apart from taking twice the memory, is that the threads have to be sort of synchronised. They'll end up waiting for each other. The graphics thread has to wait till the buffers are swapped, or the gameplay thread has to wait until the graphics one finishes.