Multi-threaded 3d Engine

This is based on no scientific fact whatsoever so i''m sure i''ll be shot down but...

The main reason I use separate threads is when I don''t want to have to monkey around with the message queue. However, when developing games, one tends to cooperate with the message queue, putting the game loop inside the message processing loop (on Windows at least).

However, I think it would come into it''s own on a multiple processor machine. If one thread on one processor could handle input etc. and a second thread on another processor could handle all the maths physics, it would be a wonderful dream come true, no?

Multithreading has little advantage on a single processor machine in general, and that''s the greater majority of your gamer''s market right there. Decoupling scene update and scene rendering in two threads involves a lot of inter-thread communication and locking, probably too much so that it hinders the overall performance. There are, however, two areas in a game where they would be useful:

1) anything that involves a fair amount of polling {such as multiplayer networking}, and

2) anything that involves scheduling complex calculations across a larger number of video frames {such as strategic AI or group-based behavioral animations}.

-cb

If you wish to seperate threads, a general rule of thumb is to find all blocks in your code. For example, receiving from a blocking winsock won''t return until a message has been received. If your code waits for a block like that, your entire engine would then wait.

For this reason, lots of people poll instead of block. So instead of saying waiting for a message to come in, they check if a new message exists, and if so they receive.

I am writing an engine that does the opposite. I dislike having to poll constantly. It makes more sense to me to have a seperate thread for each potential bottleneck. Then your engine will run smoothly and it would be more rare to notice any slowdown. A general rule of thumb is to find each block and put it in its own thread.

Blocks give up their time slice, so in our previous winsock example, the thread would give up its time slice and it would seem as if the thread isn''t even there.

Another thing to keep in mind is that if one thread is waiting for another, windows assigns a higher thread priority (temporarily) to the working thread so it can return to normal more quickly. This happens with functions like WaitForObject()

This means if you plan carefully, you can have your program assign a higher thread priority in times of need. For example, a path finding algo may need more time to find the path at first, but once found, following the path and recalculating based on simpler rules. You may want to assign a higher thread priority for a short while so it can do that burst of difficult code.

I hope this helps!