Threading in Games

[Sigvatr]

Hi there,

Lately I've been investigating the possible uses of threading in computer game, of which I am aware that there are quite a few that are quite commonly utilized.

I have no problems making use of threads, but I was wondering about what possible uses you can think of for them in computer games. I am working on a sidescrolling, networked multiplayer game, so threading applicable to those particular game attributes would be the most helpful. What ways do game programmers make use of threads in those particular contexts and game programming in general?

I have thought of a few uses of threads so far, although I have not implemented them as I know very little about the practical applications of threading. I would appreciate advisory commentary and recommendations based on the following applications of threading:

* Video rendering (OpenGL) independent of the game logic loop allowing uncapped frame rates regardless of the rate at which the game loop iterates. I understand that OpenGL is not threading friendly, but I figure that this won't be a problem as long as OpenGL operations are confined to a single thread. I've heard something about deltas? I'm not exactly sure what they are, but I think they have something to do with predicting the positions and states of things regardless of the game's frame rate?

* Audio handling and playback, especially with regards to synthesizing sound effects and procedural and dynamic generation of music. I'm very interested in real-time, procedurally generated content in general. I'm not sure what audio library to use in my game yet, but I'm sure that threading is important to audio in general.

* Window message management and handling. I've noticed one a few occasions that if my program is performing a complex function that could takes several seconds to perform, my operating system (Windows 7) will regard the application as not responding and crash it. Perhaps using a thread to receive and handle window and system messages (ideally at specific intervals) could help to solve problems like this.

* Artificial intelligence, perhaps?

Those are all of the uses I'd like to make of threads at the moment. However, I don't really know where to begin. Does anyone have any advice they could offer me on how to pursue this? Links to articles/tutorials would be good too.

Generally speaking, any and all thread related discussion here is a good thing!

Thanks!
- Sig

* Networking. I haven't started on my network code yet, but I'm sure having at least one thread to receive and interpret network data is essential.

[D_Drmmr]

* Window message management and handling. I've noticed one a few occasions that if my program is performing a complex function that could takes several seconds to perform, my operating system (Windows 7) will regard the application as not responding and crash it. Perhaps using a thread to receive and handle window and system messages (ideally at specific intervals) could help to solve problems like this.

You already have a thread that handles all windows messages and that is your main thread. Keep it that way and move any heavy processing to a worker thread.

Those are all of the uses I'd like to make of threads at the moment. However, I don't really know where to begin. Does anyone have any advice they could offer me on how to pursue this? Links to articles/tutorials would be good too.

Try to identify independent tasks in your program. Then restructure you program such that it doesn't matter in which thread a task is performed. Then you can use a thread pool to process the tasks and use as many threads as is optimal for the hardware.

[pedro00pedro]

I recomend creating diferent threads for audio and music. Doing so will make easy the volume management, and you can simply put sliders in the in-game menu to handle volume of audio and music independently.

[dexblack]

When building a multithreaded system of any sort one of the big issues is data handling.
Threads can all 'see' process' memory, but when it comes to sharing one usually splits reader/writer roles.
There is a common pattern of single writer multiple reader which often applies in games.
This is because the 'writer' corresponds to the game's user and the 'readers' are the various threads handling the resulting rush of actions that must be performed in response.
There are many tomes and articles on the subject of queueing theory, lock free structures and thread safe data handling. AFAICT you are already on the right track w.r.t. responsiveness and separation of concerns. Just remember that even the most fantastically written multithreaded application can end up being slower than the equivalent single threaded app on a single core CPU and try to ensure that every thread is contributing something necessary (and truly separate) to the whole. The biggest thing that kills MT projects is losing sight of the cost of data coupling in terms of thread contention.